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Abstract 


This document is intended for the implementers of software that use 
email to send to facsimiles using RFC 2305 and 2532. This is an 
informational document and its guidelines do not supersede the 
referenced documents. 
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1. Introduction 


This document clarifies published RFCs which standardize facsimile 
communications using Internet Email. The intent is to prevent 
implementations that deviate in such a way as to cause 
interoperability problems. 


1.1 Organization of this document 


This document contains four sections that clarify, in order, the 
handling of simple mode fax messages, extended mode fax messages, the 
file format, and the internet addressing of fax recipients. 


See Section 2 for terminology. 


1.2 Discussion of this document 


Discussion of this document should take place on the Internet fax 
mailing list hosted by the Internet Mail Consortium (IMC). Please 
send comments regarding this document to: 


ietf-fax@imc.org 
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To subscribe to this list, send a message with the body ’subscribe’ 
to "ietf-fax-requestlimc.org". 


To see what has gone on before you subscribed, please see the mailing 
list archive at: 


http: //www.imc.org/ietf-fax/ 
2. Terminology 
The following terms are used throughout this document: 


DSN - RFC 1894, "An Extensible Message Format for 
Delivery Status Notifications" [7] 
RFC 2532, "Extended Facsimile Using 
Internet Mail" [3] 
MDN - RFC 2298, "An Extensible Message Format for 
Message Disposition Notifications" [9] 
RFC 2305, "A Simple Mode of Facsimile 
Using Internet Mail" [2] 


Extended Mode 


Simple Mode 


TIFF - profile S or F of "File Format for Internet Fax" [4] 
delivered as "image/tiff" 

TIFF-FX - other profiles sent as "image/tiff-fx" 

In examples, "C:" is used to indicate lines sent by the client, and 

"S:" to indicate those sent by the server. 


3. Implementation Issues Specific to Simple Mode 
Issues specific to Simple Mode [2] are described below: 

3.1 Simple Mode Fax Senders 

3.1.1 Multipart/alternative 
Although a requirement of MIME compliance (16, Section 5.1.4), some 
email client implementations are not capable of correctly processing 
messages with a MIME Content-Type of "multipart/alternative". Ifa 
sender is unsure if the recipient is able to correctly process a 


message with a Content-Type of "multipart/alternative", the sender 
should assume the worst and not use this MIME Content-Type. 
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3.2 Simple Mode Fax Receivers 
3.2.1 Multipart/alternative and Storage Capacity 


Devices with little storage capacity are unable to cache previous 
parts of a multipart/alternative message. In order for such devices 
to correctly process only one part of a multipart/alternative 
message, such devices may simply use the first part of a 
multipart/alternative message it is capable of processing. 


This behavior means that even if subsequent, higher-fidelity parts 
could have been processed, they will not be used. 


This behavior can cause user dissatisfaction because when two high- 
fidelity but low-memory devices are used with each other, the 
lowest-fidelity part of the multipart/alternative will be processed. 


The solution to this problem is for the sender to determine the 
capability of the recipient and send only high fidelity parts. 
However, a mechanism to determine the recipient capabilities prior to 
an initial message sent to the recipient doesn’t yet exist on the 
Internet. 


After an initial message is sent, the Extended Mode mechanism, 
described in RFC 2532 [3], Section 3.3, enables a recipient to 
include its capabilities in a delivery and/or a disposition 
notification: in a DSN, if the recipient device is an RFC 2532/ESMTP 
[3] compliant server or in an MDN if the recipient is a User Agent. 


4. Implementation Issues Specific to Extended Mode 
Issues specific to Extended Mode [3] fax are described below. Note 
that any Extended Mode device also needs to consider issues specific 
to Simple Mode (Section 3 of this document). 
4.1 Multipart/Alternative 
Sections 3.1.1 and 3.2.1 are also applicable to this mode. 
4.2. Correlation of MDN with Original Message 
To re-iterate a paragraph from section 2.1, RFC 2298 [9]: 
A message that contains a Disposition-Notification-To header 
SHOULD also contain a Message-ID header, as specified in RFC 822 


[10]. This will permit automatic correlation of MDNs with 
original messages by user agents. 
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4.3 Correlation of DSN with Original Message 


Similar to the requirement to correlate an MDN, above, DSNs also need 
to be correlated. This is best done using the ENVID parameter in the 
"MAIL" command. See Sections 3 and 5.4 of RFC 1891 [5] for details. 


4.4 Extended Mode Receivers 


Confirmation that the facsimile image (attachment) was delivered and 
successfully processed is an important aspect of the extended mode of 
the facsimile using Internet mail. This section describes 
implementation issues with several types of confirmations. 


4.4.1 Confirmation of receipt and processing from User Agents 


When a message is received with the "Disposition-Notification-To" 
header and the receiver has determined whether the message can be 
processed, it may generate a: 


a) Negative MDN in case of error, or 
b) Positive MDN in case of success 


The purpose of receiving a requested MDN acknowledgement from an 
Extended Mode recipient is the indication of success or failure to 
process the file attachment that was sent. The attachment, not the 
body, constitutes the facsimile message. Therefore an Extended Mode 
sender would expect, and it is recommended that the Extended Mode 
receiver send (with an MDN), an acknowledgement of the success or 
failure to decode and process the file attachment. 


Implementers of the Extended Mode [3] should be consistent in the 
feedback provided to senders in the form of error codes and/or 
failure/success messages. 


4.4.1.1 Discrepancies in MDN [9] Interpretation 


An Extended Mode sender must be aware that RFC 2298 [9] does not 
distinguish between the success or failure to decode the body-content 
part of the message and the success or failure to decode a file 
attachment. Consequently MDNs may be received which do not reflect 
the success or failure to decode the attached file, but rather to 
decode the body-content part of the message. 
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4.4.1.2 Disposition-Type and body of message in MDN 


If the receiver of an MDN request is an RFC 2532 compliant device 
that automatically prints the received Internet mail messages and 
attachments, or forwards the attachment via GSTN fax, it should, in 
the case of success: 


a) Use a "disposition-type" of "dispatched" (with no "disposition- 
modifier") in the MDN, and 


b) Use text similar to the following in the body of the message: 


"This is a Return Receipt for the mail that you sent to [above, or 
below, or this address, etc]. The message and attached files[s] 
may have been printed, faxed or saved. This is no guarantee that 
the message has been read or understood". 


and in the case of failure: 


a) Use a "disposition-type" of "processed" and disposition-modifier 
of "error", and 


b) Use text similar to the following in the body of the message: 


"This is a Return Receipt for the mail that you sent to [above, or 
below, or this address, etc]. An error occurred while attempting 
to decode the attached file[s]". 


This recommendation adheres to the definition in RFC 2298 [9] and 
helps to distinguish the returned MDNs for proper handling. 


Implementers may wish to consider sending messages in the language of 
the sender (by utilizing a header field from the original message) or 
including multiple languages, by using multipart/alternative for the 
text portion of the MDN. 


4.4.2 "Subject" of MDN and DSN in Success and Failure Cases 
Because legacy e-mail applications do not parse the machine-readable 


headers, e-mail users depend on the human-readable parts of the MDN 
to recognize the type of acknowledgement that is received. 


Examples: 
MDN: 


Subject: Your message was processed successfully. (MDN) 
Subject: Your message has been rejected. (MDN) 
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DSN: 
Subject: Your message was delivered successfully. (DSN) 
Subject: Your message could not be delivered. (DSN) 
Subject: Your message is delayed. (DSN) 


4.4.3 Extended Mode Receivers that are MTAs (or ESMTP servers) 


SMTP server-based implementations are strongly encouraged to 
implement the "SMTP Service Extension for Returning Enhanced Error 
Codes" [8]. This standard is easy to implement and it allows 
detailed standardized success and error indications to be returned to 
the sender by the submitting MTA. 


The following examples, are provided as illustration only. They 
should not be interpreted as limiting the protocol or the DSN form. 
If the examples conflict with the definitions in the standards (RFC 
1891[5]/1893[6]/1894[7]/2034[8]), the standards take precedence. 


4.4.3.1 Success Case Example 
In the following example the sender <jean@example.com> sends a 
message to the receiver <ifax@example.net> which is an ESMTP server 


and the receiver successfully decodes the message. 


example.com 


F======= + 
| Mail | 
User 
Agent 
Ho + 
| 
V 
Ho + Ho + Ho + 
Mail + Mail Mail 
Submission |----- >|Transfer|---->|Transfer 
| Agent | | Agent | | Agent | 
232235 + Ho + d====5223= + 
example.org example.net 
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SMTP Sequence: 


220 example.net SMTP service ready 

EHLO example.org 

250-example.net 

250-DSN 

250 ENHANCEDSTATUSCODES 

MAIL FROM:<jean@example.com> RET=HDRS ENVID=MM123456 
250 2.1.0 Originator <jean@example.com> ok 

RCPT TO:<ifax@example.net> NOTIFY=SUCCESS, FAILURE \ 
ORCPT=rfc822;ifax@example.net 

250 2.1.5 Recipient <ifax@example.net> ok 

DATA 

354 Send message, ending in <CRLF>.<CRLF> 


ANANNNAN 


[Message goes here. ] 


250 2.0.0 Message accepted 
QUIT 
221 2.0.0 Goodbye 


NDMQANDAAARAANAN 


DSN (to jean@example.com): 


Date: Mon, 12 Dec 1999 19:01:57 +0900 

From: postmaster@example.net 

Message-ID: <19991212190157.01234@example.net> 

To: jean@example.com 

Subject: Your message was delivered successfully. (DSN) 

MIME-Version: 1.0 

Content-Type: multipart/report; report-type=delivery-status; 
boundary=JUK199912121854870001 


--JUK199912121854870001 
Content-type: text/plain 


Your message (id MM123456) was successfully delivered 
to ifax@example.net. 


--JUK199912121854870001 
Content-type: message/delivery-status 
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Reporting-MTA: dns; example.net 

Original-Envelope-ID: MM123456 

Final-Recipient: rfc822;ifax@example.net 

Action: delivered 

Status: 2.1.5 (Destination address valid) 

Diagnostic-Code: smtp; 250 2.1.5 
Recipient <ifax@example.net> ok 


--JUK199912121854870001 
Content-type: message/rfc822 


[headers of returned message go here.] 
--JUK199912121854870001-- 
4.4.3.2 Failure Case Example 1 
In this example, the receiver determines it is unable to decode the 
attached file AFTER it has received the SMTP message. The receiver 


then sends a ’failure’ DSN. 


example.com 


AS Ses + 
| Mail | 
| User | 
| Agent | 
+e SSS + 
| 
V 
Ho + Ho + Ho + 
| Mail + | Mail | | Mail 
| Submission |----- >|Transfer|---->|Transfer | 
| Agent | | Agent | | Agent | 
Ho + Ho + Ho + 
example.org example.net 
SMTP Sequence: 
This is the same as the case a). After the sequence, a decode 


error occurs at the receiver, so instead of a ’success’ DSN, a 
“failure” DSN is sent. 
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DSN (to jean@example.com): 


Date: Mon, 12 Dec 1999 19:31:20 +0900 

From: postmaster@example.net 

Message-ID: <19991212193120.87652@example.net> 

To: jean@example.com 

Subject: Your message could not be delivered. (DSN) 

MIME-Version: 1.0 

Content-Type: multipart/report; report-type=delivery-status; 
boundary=JUK199912121934240002 


--JUK199912121934240002 
Content-type: text/plain 


Your message (id MM123456) to ifax@example.net resulted in an 
error while attempting to decode the attached file. 


--JUK199912121934240002 

Content-type: message/delivery-status 
Reporting-MTA: dns; example.net 
Original-Envelope-ID: MM123456 
Final-Recipient: rfc822;ifax@example.net 
Action: Failed 

Status: 5.6.1 (Media not supported) 
Diagnostic-Code: smtp; 554 5.6.1 Decode error 


--JUK199912121934240002 
Content-type: message/rfc822 


[headers of returned message go here.] 
--JUK199912121934240002-- 
4.4.3.3 Failure Case Example 2 


In this example, the receiver determines it is unable to decode the 
attached file BEFORE it accepts the SMTP transmission. 


Cancio, et. al. Informational [Page 10] 


RFC 


4.4 


3249 Implementers Guide for Facsimile September 2002 


SMTP sequence: 


S: 220 example.net SMTP service ready 
C: EHLO example.org 
S: 250-example.net 
S: 250-DSN 
S: 250 ENHANCEDSTATUSCODES 
C: MAIL FROM:<jean@example.com> RET=HDRS ENVID=MM123456 
S: 250 2.1.0 Originator <jean@example.com> ok 
C: RCPT TO:<ifax@example.net> NOTIFY=SUCCESS,FAILURE \ 
ORCPT=rfc822;ifax@example.net 
S: 250 2.1.5 Recipient <ifax@example.net> ok 
C: DATA 
S: 354 Send message, ending in <CRLF>.<CRLF> 
Es 
Gs [Message goes here. ] 
Es 
Ce fs 
S: 554 5.6.1 Media not supported 
€: QUIT 
S: 221 2.0.0 Goodbye 
DSN: 


Note: In this case, the previous MTA generates the DSN that is 
forwarded to the original sender. The receiving MTA has not 
accepted delivery and therefore can not generate a DSN. 


.4 Extended Mode Receivers that are POP3/IMAP4 


NOTE: This document does not define new disposition-types or 
disposition-modifiers. Those used below are defined in RFC 
2298[9]. This section provides examples on how POP3/IMAP4 devices 
may use the already defined values. 


These examples are provided as illustration only. They should not be 
interpreted as limiting the protocol or the MDN form. If the 
examples conflict with the MDN [9] standard, the standard takes 
precedence. 


-4.1 Success Case Example 


If the original sender receives an MDN which has "displayed", 
"dispatched" or "processed" disposition-type without disposition- 
modifier, the receiver may have received or decoded the attached file 
that it sent. The MDN does not guarantee that the receiver displays, 
prints or saves the attached file. See Section 4.4.1.1, 
Discrepancies in MDN Interpretation. 
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NOTE: This example does not include the third component of the 
MDN. 


Date: 14 Dec 1999 17:48:44 +0900 

From: ken_recipient@example.com 

Message-ID: <19991214174844.98765@example.com> 

Subject: Your message was processed successfully. (MDN) 

To: mary@example.net 

Mime-Version: 1.0 

Content-Type: multipart/report; 
report-type=disposition-notification; boundary="61FD1001_IFAX" 


--61FD1001_IFAX 
Content-Type: text/plain 


This is a Return Receipt for the mail that you sent to 
"ken_recipient@example.com". The message and attached files may 
have been printed, faxed or saved. This is no guarantee that the 
message has been read or understood. 


--61FD1001_IFAX 
Content-Type: message/disposition-notification 


Reporting-UA: ken-ifax.example.com; barmail 1999.10 
Original-Recipient: rfc822;ken_recipient@example.com 
Final-Recipient: rfc822;ken_recipient@example.com 
Original-Message-1D: <199912141740100.mary@example.net> 
Disposition: automatic-action/MDN-sent-automatically; dispatched 


--61FD1001_IFAX-- 
4.4.4.2 Failure Case Example 


If the original sender receives an MDN with an "error" or "warning" 
disposition-modifier, it is possible that the receiver could not 
receive or decode the attached file. Currently there is no mechanism 
to associate the disposition-type with the handling of the main 
content body of the message or the attached file. 


Date: 14 Dec 1999 19:48:44 +0900 

From: ken_recipient@example.com 

Message-ID: <19991214194844.67325@example.com> 

Subject: Your message has been rejected. (MDN) 

To: mary@example.net 

Mime-Version: 1.0 

Content-Type: multipart/report; 
report-type=disposition-notification; boundary="84FD1011_IFAX" 
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--84FD1011_IFAX 
Content-Type: text/plain 


This is a Return Receipt for the mail that you sent to 
"ken recipientltexample.com". An error occurred while attempting 
to decode the attached file[s]". 


--84FD1011_IFAX 
Content-Type: message/disposition-notification 


Reporting-UA: ken-ifax.example.com; barmail 1999.10 

Original-Recipient: rfc822;ken_recipient@example.com 

Final-Recipient: rfc822;ken_recipient@example.com 

Original-Message-1D: <199912141823123.mary@example.net> 

Disposition: automatic-action/MDN-sent-automatically; 
processed/error 


--84FD1011_IFAX 
Content-Type: message/rfc822 


[original message goes here] 
--84FD1011_IFAX-- 
4.4.5 Receiving Multiple Attachments 


A received email message could contain multiple attachments and each 
distinct attachment could use TIFF or TIFF-FX with different 
encodings or resolutions, and these could be mixed with other file 
types. 


There is currently no mechanism to identify, in a returned MDN, the 
attachments that were successfully decoded from those that could not 
be decoded. 


If the Extended Mode recipient is unable to decode any of the 
attached files, it is recommended that the Extended Mode recipient 
return a decoding error for the entire message. 


5. Implementation Issues Specific to the File Format 
5.1 IFD Placement & Profile-S Constraints 
a) An IFD is required, by TIFF 6.0, to begin on a word boundary, 


however, there is ambiguity with regard to the defined size of a 
word. A word should be interpreted as a 2-byte quantity. This 
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recommendation is based on examination of Figure 1 and the 
definition of IFD Entry, Bytes 8-11, found in Section 2 of TIFF 
6.0. 


Low memory devices, which support resolutions greater than the 
required Profile-S, may be memory-constrained, such that those 
devices cannot properly handle arbitrary placement of TIFF IFDs 
within a TIFF file. 


To interoperate with a receiver that is constrained, it is 
strongly recommended that senders always place the IFD at the 
beginning of the image file when using any of the Profiles defined 
in [4]. 


5.2 Precautions for implementers of RFC 2301 [4] 


5.2.1 Errors encountered during interoperability testing 


The TIFF/RFC 2301 [4] errors listed below were encountered during 
interoperability testing and are provided so that implementers of 
TIFF readers and writers can take precautionary measures. 


a) 


Although Profile S of TIFF [4] specifies that files should be in 
little-endian order, during testing it was found that some common 
TIFF writers create big-endian files. If possible, the TIFF 
reader should be coded to handle big-endian files. TIFF writers 
should always create little-endian files to be compliant with the 
standard and to allow interoperation with memory-constrained 
devices. 


Bytes 0-1 of the Image File Header are supposed to be set to "II" 
(4949h) or "MM" (4d4dh) to indicate the byte order. During 
testing, other values were encountered. Readers should handle 
cases where the byte order field contains values other than "II" 
or "MM", and writers should ensure the correct value is used. 


5.2.2 Color Gamut Considerations 


The ITULAB encoding (PhotometricInterpretation = 10) allows choosing 
a gamut range for L*a*b* (see the TIFF field Decode), which in turn 
provides a way to place finer granularity on the integer values 
represented in this colorspace. But consequently, an inadequate 
gamut choice may cause a loss in the preservation of colors that 
don’t fall within the space of colors bounded by the gamut. As such, 
it is worth commenting on this. 
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The ITULAB default gamut, L [0,100] a [-85,85] b [-75,125], was 
chosen to accommodate most scan devices, which are typically acquired 
from a hardcopy source. It wasn’t chosen to deal with the range of 
color from camera input or sRGB monitor data. In fact, when dealing 
with images from the web and other display oriented sources, the 
color range for a scanned hardcopy may likely be inadequate. It is 
important to use a gamut that matches the source of the image data. 


The following guidelines are recommended: 


1. When acquiring input from a printed hardcopy source, without 
modification, the ITU-T Recommendation T.42 default ITULAB gamut 
should be appropriate. 


2. For an sRGB source, the ITU-T Recommendation T.42 default ITULAB 
gamut is not appropriate. A more appropriate gamut to consider 
is: L [0,100], a [-88,99] and b [-108.8,95.2]. These may be 
realized by using the following Decode values for 8-bit data: 
(0/1, 100/1, -22440/255, 25245/255, -27744/255, 24276/255). 


3. If the range of L*a*b* value can be precomputed efficiently before 
converting to ITULAB, then you may get the best result by picking 
a gamut that is custom to this range. 


5.2.3 File format Considerations 


Implementers should make sure of the contents in the following two 
sections. 


5.2.3.1 Considerations for greater reader flexibility 
a) Readers are able to handle cases where IFD offsets point beyond 


the end of the file, while writers ensure that the IFD offset does 
not point beyond the end of the file. 


b) Readers are able to handle the first IFD offset being on a non- 
word boundary, while writers ensure that the first IFD offset is 
on a word boundary. 


c) Readers are flexible and able to accommodate: IFDs that are not 
presented in ascending page order; IFDs that are not placed at a 
location that precedes the image which the IFD describes; next IFD 
offsets that precede the current IFD, the current IFDs’ field 
data, or the current IFDs’ image data. Writers on the other hand 
should generate files with IFDs presented in ascending page order; 
IFDs placed at a location that precedes the image which the IFD 
describes; the next IFD should always follow the current IFD and 
all of its data. 
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d) Writers generate tags with the appropriate type of data (for 
example RATIONAL instead of SRATIONAL). Readers are flexible with 
those types of misrepresentations that may be readily accommodated 
(for example SHORT instead of LONG) and lead to enhanced 
robustness. 


e) The appropriate count is associated with the tags (it is not 0 and 
matches the tag requirement), while readers are flexible with 
these types of misrepresentations, which may be readily 
accommodated and lead to enhanced robustness. 


f) Tags appear in the correct order in the IFD and readers are 
flexible with these types of misrepresentations. 


5.2.3.2 Error considerations 


a) Readers only accept files with bytes 2-3 of the Image File Header 
equal to 42 (2Ah), the "magic number", as being valid TIFF or 
TIFF-FX files, while writers only generate files with the 
appropriate magic number. 


b) Files are not generated with missing field entries, and readers 
reject any such files. 


c) The PageNumber value is based on the order within the Primary IFD 
chain. The ImageLayer values are based on the layer order and the 
image order within the layer respectively. Readers may reject the 
pages where the PageNumber or ImageLayer values are not consistent 
with the number of Primary IFDs, number of layers or number of 
images within the layers. 


d) Tags are unique within an IFD and readers may reject pages where 
this is not the case. 


e) Strip data does not overlap other file data and the reader may 
error appropriately. 


f) The strip offset does not point outside the file, under these 
conditions readers may reject the page where this is the case. 


g) The strip offset + StripByteCounts does not point outside the 
file, under these conditions the reader may error appropriately. 


h) Only one endian order is used within the file otherwise the 
rendered file will be corrupted. 
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i) Tag values are consistent with the data contained within the image 
strip. For example, a bi-level black mark on a white background 
image strip with a PhotometricInterpretation tag value of "1" (bit 
value of "0" means black) will result in the rendering of the 
image as white marks on a black background (reverse video). 


j) For the special color spaces (ITULAB, YCBCR, CMYK), the parameters 
used for transformations are correct and compliant with the 
specification. 


k) The XPosition and YPosition values are consistent with the 
horizontal and vertical offsets of the top-left of the IFD from 
the top-left of the Primary IFD, in units of the resolution. To 
do otherwise results in misplacement of the rendered image. 


1) All combinations of tag values are correct, with special attention 
being given to the sets: XResolution, YResolution and ImageWidth; 
PhotometricInterpretation, SamplesPerPixel, and BitsPerSample. 

Any appropriate combinations will likely result in image 
distortion or an inability to render the image. 


m) The appropriate Compression types are used for the image layers 
within a Profile M file, such as a bi-level coder for the mask 
layers (i.e. odd numbered layers) and multi-level (color) coders 
for the background and foreground layers. Readers should reject 
files where this is not true. 


5.3 Content-Type for the file format 


The content-type "image/tiff" should only be used for Profiles S and 
F. Some existing implementations based on [4] may use "image/tiff" 
for other Profiles. However, this usage is now deprecated. Instead, 
the content-type "image/tiff-fx", whose registration is being defined 
in [17] should be used. 


To maximize interworking with devices that are only capable of 
rendering Profile S or F, "image/tiff" SHOULD be used when 
transporting Profile S or F. 


6. Implementation Issues for Internet Fax Addressing 
The "+" and "=" characters are valid within message headers, but must 
be encoded within some ESMTP commands, most notably ORCPT [5]. 


Implementations must take special care that ORCPT (and other ESMTP 
values) are properly encoded. 
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For example, the following header is valid as-is: 
To: Home Fax <FAX=+390408565@example.com> 
but when used with ORCPT, the "=" and "+" must be encoded like this: 


RCPT TO:<FAX=+390408565@example.com> \ 
ORCP T=FAX+3D+2B390408565@example.com 


Note the "=" and "+" are valid inside the forward-path, but must be 
encoded when used within the esmtp value. 


See [5] for details on this encoding. 
7. Security Considerations 


With regards to this document, Sections 5 in RFC 2305 [2] and Section 
4 in RFC 2532 [3] apply. 
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This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
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followed, or as required to translate it into languages other than 
English. 
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revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
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